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Universal Configurable Machine (UCM) in 
Embedded Control Applications 



Applications in the embedded control area are primarily event-controlled. This is due to 
the fact that, because the controller is embedded in the higher-ranking machine, the non- 
deterministic sequence of events mandates a special program form for event handling 
instead of algorithmic-deterministic programming. 

Normally these external interruptions are handled by interrupt service routines within the 
overall application, i.e. embedded in real-time operating systems. A real-time operating 
system contains a special part for this purpose, the task management system (TMS), 
which contains an anomaly compared with the other basic parts of an operating system. 
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Fig. 1 : Columns of an operating system 

The basic input output system (BIOS), disk operating system (DOS) and memory 
management system (MMS) give the user a higher functionality than the simple 
processor; they form a virtual machine. TMS (in real-time operating systems), on the 
other hand, manages the computing time deficit; i.e., above all the computing capacity of 
the processor is distributed in such a way that the requirements of the outside world are 
mirrored in the available computing time in accordance with the specifications. 



The system designer, however, has only an indirect influence on the real-time 
functionality in that he has to rely on the operating system and its specifications. 
Especially the verification of the application with respect to the response being correct in 
terms of time (and mathematically) in all circumstances under hard real-time conditions 
is an extremely intensive process, and in some cases even impossible. This is where 
USM architecture (Fig. 2) comes into play: 
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Abb/2: Blockstruktur UCM 

Fig. 2: Block Structure UCM 



USM architecture consists of two main components. The control unit, essentially the 
same as in previous microcontrollers, controls the processing of the main program, i.e. 
the actual application. For this purpose it uses one or more universal configurable blocks 



(UCB) 5 which are comparable to reconfigurable arithmetical logical units and which 
process commands in blocks. 

The second part is very important for the new type of processing in controllers and 
consists of (small) UCBs and a scheduler integrated in hardware. This scheduler is 
responsible for allocating computing time and monitoring control flow, which exists in 
so-called threads (Befehlsfaderi). This architecture gives UCM architecture the following 
characteristics: 

• It is a single processor multiblock system rather than a multiprocessor system. A 
great advantage of this is that it is not necessary to perform intensive processor 
synchronizations, but merely to have a central unit as a distribution entity for 
computing time demand. 

The multiblock system offers parallel computing capacity and is optimized for 
threads. Threads form the optimal basis for system integration in the context of 
interruption processing, which - as explained - [is] essential to embedded control 
applications. 

• The developer is able to build a deterministic application in the real-time domain as 
well with the aid of UCM architecture. This is possible through the explicit, 
possibly even exclusive, allocation of UCBs to threads for high-priority interrupts, 
without any load being placed on the core CPU. The operating system block for 
task management, whose deterministic behavior is so difficult to estimate, is either 
completely replaced by hardware or restricted to a few critical paths. 

UCBs are based on the principle of structural programming (field programmable 
logic similar to FPGAs) and are therefore substantially faster compared with 
sequential processing using processors. This results in a dramatic acceleration of 
the thread processing to the application's benefit. 

On the other hand, some studies have already shown that the program environment 
hardly has to be changed for UCBs compared with normal CPUs. For the software 
developer, the programming language remains the same, and known compiler 
technologies can be used, particularly for optimization. Upgrades remain highly 
limited, they can be integrated in hardware (controller) or in software, and they 
remain hidden to the developer. 

The multiblock design of UCM architecture additionally makes possible an error 
tolerance with respect to component failure, because instruction blocks can be 
routed from the scheduler and the control unit to a functioning UCB as needed. 

Conclusion: UCM architecture makes it possible to design controllable deterministic 
applications even in the complex field of real-time applications. There is greater 
consistency between the description and the real machine because the part of the virtual 
machine operating system TMS which has to be considered one of the least deterministic 
is replaced by the real machine. UCM increases the controllability of embedded control 
applications while exhibiting tolerance to component failure. 
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Applikationen im Embedded-Control-Bereich sind tiberwiegend Ereignis-gesteuert. Der Grund hierflir ist in der 
Einbettung des Controllers in die ubergeordnete Maschine zu sehen, die durch die nicht-determinstische Folge 
von Ereignissen keine algorithmisch-deterministische Programmierung ermoglicht, sondem eine spezielle 
Programmform zur Bedienung der Ereignisse erzwingt 

Ublicherweise werden diese externen Uhterbrechungen durch Intemipt-Service-Routinen innerhalb der 
Gesamtapplikation bzw. eingebettet in Echtzeit-Betriebssysteme bedient. Ein Echtzeit-Betriebssystem enthalt filr 
diesen Zweck einen besonders ausgeprSgten Teil, das Task Management System (TMS), das verglichen mit den 
anderen Basisteilen eines Betriebssystem eine Besonderheit enthSlt. 
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Abb. 1 : Saulen eines Betriebssystems ' 

Basic Input Output System (BIOS), Disk Operating System (DOS) und Memory Management System (MMS) 
stellen dem Anwender eine gegenttber^dem einfachen Prozessor hOhere Funktionalitat zur Verfilgung, sie bilden 
eine virtuelle Maschine. TMS (in Echtzeit-Betriebssystemen) hingegen verwaltet den Mangel an Rechenzeit, 
d.h., es wird vor allem die Rechenkapazitat des Prozessors so verteilt, daJ} die Anforderungen der AuBenwelt 
den Spezifikationen entsprechend auf die zur Verfilgung stehende Rechenzeit abgebildet werden. 

Der Systemdesigner aber hat nur mittelbaren EinfluB auf die Echtzeitfunktionalitat > indem er sich auf das 
Betriebssystem und dessen Spezifikationen verlassen mufi. Insbesondere die Verifikation der Applikation, bei 
harten Echtzeitbedingungen unter alien Umstanden zeitlich (und rechnerisch) korrekt zu reagieren, ist sehr 
aufwendig, ggf. sogar unmoglich. Hier setzt die UCM-Architektur (Abb. 2) an: 
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Abb. '2: Blockstruktur UCM 

Die UCM-Architektur besteht aus zwei Hauptkomponenten. Die Control Unit, im wesentlichen unverandert 
gegentlber den bisherigen Mikrocontrollern, steuert die Bearbeitung des Hauptprogramms, also der eigentlichen 
Applikation. Sie nutzt hierzu ein oder mehrere Universal Configurable Blocks (UCB), die ihrerseits mit einer 
rekonfigurierbaren Arithmetical Logical Unit vergleichbar sind und die Befehle blockweise abarbeiten. 

Der zweite Teil ist sehr wichtig fur die neue Form der Bearbeitung in Controllem und besteht aus (kleinen) 
UCBs sowie einem in Hardware integrierten Scheduler. Dieser Scheduler ist verantwortlich filr die Zuteilung 
von Rechenzeit und OberwachungskontrollfluB, der in sogenannten Threads (Befehtefaden) vorliegL Durch 
diese Architektur ergeben sich folgende Charakteristika filr die UCM-Architektur: 

• Es handelt sich nicht urn ein Multiprozessorsystem, sondem um ein Einprozessor-Multiblocksystem. Dies 
hat den groBen Vorteil, keine aufwendigen Prozessorsynchronisationen durchfuhren zu mussen, sondem eine 
zentrale Einheit als Verteilungsinstanz fUr Rechenzeitbedarf zu besitzen. 



Das Multiblocksystem bietet parallele Rechenkapazitat an und ist auf Threads optimiert. Threads bilden im 
Rahmen der Unterbrechungsbearbeitung, die - wie bereits dargestellt - fUr Embedded Controlapplikationen 
sehr wesentlich sind, die optimale Grundlage zur Systemintegration. 

• Der Entwickler ist in der Lage, mit Hilfe der UCM-Architektur eine deterministische Applikation auch im 
Echtzeitbereich aufzubauen. Dies erfolgt durch die explizite, ggf. sogar exkliisive Zuordnung von UCBs zu 
Threads bei hochpriorisierten Interrupts, ohne daB hierdurch die Kern-CPU belastet wird. Der in seiner 
Deterministik schwierig abzuschatzende Betriebssy stem-Block fur Task Management wird entweder 
vollstandig durch die Hardware ersetzt oder auf weniger kritische Pfade eingeschrankt 

• Die UCBs basieren auf einem Prinzip der strukturalen Programmierung (Feldprogrammierbare Logik ahnlich 
zu FPGAs) und sind dementsprechend wesentlich schneller verglichen mit sequentieiler Bearbeitung durch 
Prozessoren. Dies resultiert in einer drastischen Beschleunigung der Thread-Bearbeitung zum Vorteil der 
Applikation. 

Andererseits wurde durch einige Arbeiten bereits gezeigt, dafl eine Anderurlg der Programmierumgebung ftlr 
UCBs im Vergleich z!u normalen CPUs kaum erforderlich ist. FQr den Softwareentwickler bleibt die 
Programmiersprache erhalten, bekannte Compilertechnologien insbesoridere zur Optimierung kfinnen 
genutzt werden. Die Erweiterungen bleiben eng begrerizt, kOnnen sowohl in Hardware (Controller) als auch 
in Software integriert werden und bleiben fUr den Entwickler verborgen. 

• Das Multiblock-Design der UCM-Architektur erm6glicht zusatzlich eine Fe.hlertoleranz gegen Ausfall von 
Komponenten, indem die Instruktionsblficke von dem Scheduler und der Control Unit entsprechend zu 
einem funktionsfaVhigen UCB geroutet werden kOnnen. 

Fazit: Die UCM-Architektur ermOglicht, auch im schwierigen Feld der Echtzeitanwendungen beherrschbare, 
deterministische Applikationen zu erstetlen. Sie erhoht die Konsistenz zwischen Beschreibung uhd realer 
Maschine, indem der Teil der virtuellen Maschine. Betriebssy stem TMS, der als wenig deterministisch betrachtet 
werden mufi, durch die reale Maschine ersetzt wird; UCM erhOht die Beherrschbarkeit von Embedded Control 
Applikationen bei gleichzeitiger Toleranz gegenUber Ausfall von Komponenten. 
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5.1 The ASSC Architecture on the Block Level 

Fig. 5.2 shows the general structure of ASSC architecture. In this figure, the ROM 
and RAM memory areas are represented as external memories; this should be 
considered merely exemplary since integrated architectures can also be designed for a 
comparable expenditure, in part even a lower one. 
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Abb. 5-2: Blockstruktur ASSC^Architektur 

In contrast with a traditional microcontroller architecture, in ASSC architecture there 
is a layer between peripheral elements and microprocessors, which consists of 
structurable logic elements, hereafter SLE. This SLE layer contains permanent 
connections between the microprocessor core and the peripherals in order to create 
functional compatibility with previous architectures, as well as configurable data 
paths and data links whose structures will be presented in detail in the next section 
and whose coupling with the microprocessor will be presented in the section 
following the next section. 
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The SLE layer can be built in the area of the data memory in two variants: 

Variant 1 does not contain a direct interface to the data memory. This basically 
prevents competing access (core and periphery via SLE) to the data memory. 
The SLE (and via this, the peripheral elements) can access the memory 
indirectly by means of injected processor commands. 

Variant 2 contains a direct interface to the data memory (dotted lines in Fig. 5-2) 
and therefore must also offer an expanded bus interface in order to be able to 
resolve competing accesses. The advantage of this solution consists in the 
significantly faster handling of memory transfer, although it requires a larger 
outlay. 

In both variants the SLE layer otherwise has the same attributes and forms an 
intelligent, configurable interface between the periphery and the core and the 
peripheral elements. 

5.2 The Fine Structure of the Structurable Logic Elements 

Generally a unified block structure in the SLE layer is possible. This consists of one 
or two (successive) logic blocks for disjunctive normal form (or other base systems), 
so (almost) any combination of input signals can be generated. 

This architecture is highly flexible but creates a large internal wiring complexity 
because each input and output has to be led to the logic gates twice. In DNF 
architecture this leads to AND gates with a large number of inputs. For this reason, in 
this paper an additional sub-block structure is proposed, which reduces the complexity 
of the gates; this hardly diminishes the flexibility of ASSC architecture given the right 
splitting and cross-connections among blocks. 
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Abb. 5-3: Interne Struktur der SLE-Schicht 



The fine structure of the SLE layer initially comprises two internal blocks, 
represented in figure 5-3. The much smaller block serves for supplying the 
structurable hardware with various clock signals which derive from a CPU master 
clock signal. For instance, clock signals with an altered frequency, altered duty ratio 
and/or altered phase angle are generated in this subunit. 

The much larger part of the SLE layer, the actual logic blocks, contain data paths" 
which are configurable with the aid of multiplexers, registers, and a structurable logic 



2 



arrangement in the form of disjunctive normal forms ; the multiplexers and 
structurable logic can be combined. Here, individual state machines with 
corresponding decoders are implemented, which determine the coupling between the 
core and periphery and the periphery/periphery and periphery/memory coupling. 

5.2.1 Subunit for Clock Generation 

The subunit for clock generation consist of a high-speed configurable logic 
arrangement, for instance in the form of a disjunctive normal form (NICHT-UND- 
ODER logic) with a downstream configurable memory including inversion/buffering 
and feedback. As a clock signal input, this subunit contains one or more CPU clock 
signals and k number of outputs, all of which can be utilized as a clock signal inside 
the logic block subunit. Figure 5-4 shows the design on the gate level; this 
representation is based on the diagrammatic style normally used to represent 
PALs/GALs and contains the basic wiring of one internal signal and one generated 
output signal in each case. 

The DNF design (with configurable inverting) allows the generation of a number of 
clock signal variations; internal register/DNFs which are fed back also provide for 
variations with non-binary duty and division ratios. 
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Abb. 5-4: Aufbau Taktgenerierungseinheit auf Gatterebene 
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The number of different clock signals that can be generated should be no less than 4, 
whereas an upper limit is imposed by available resources. The lower limit for the 
number of terms per DNF is also 4. An internal signal should additionally be available 
for every clock signal generated. 

5.2.2 The Logic Blocks Subunit 

As already explained, the logic blocks subunit consists of a multiplicity of 
components. Among them are: 

1 . Configurable multiplexer for connecting data paths; these multiplexers may 
coincide with the structurable hardware cited below in number 4 under certain 
circumstances 

2. Registers with the corresponding bit width for data buffering 

3. Bit registers for the coding of states 

4. Structurable hardware for the decoding of states for control signals 

5. Fixed and structurable hardware for linking data with other data and with 
constants 



These components are linked with one or more logic blocks as represented in the 
following Fig. 5-5. 




Abb. 5-5: Darstellung eines Logikblocks ate Teileinheit in der SLE-Schicht 



In the I/O part of a logic block, the data can be linked with each other; this is possible 
in configurable or permanent hardware, in Fig. 5-5 the links are integrated into 
DNF la and lb. The memory function in Rl serves for buffering, whereas the constant 
register CR1 serves for the storage of calculation constants (e.g. for minimum/ 
maximum limits). 
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The multiplexer Mli (source selection) and Mlo (destination selection) connect the 
logic block with data buses to the core, memory (if allowed, e.g. in variant 2) and I/O 
elements. The constant k refers to the system f s inherent data bus width, e.g. 16 bits. 
The multiplexer Mli is key to a flexible coupling between blocks; a common 
calculation can be performed in several blocks at once for one I/O component if the 
input multiplexer is able to switch the corresponding input buses. This technique 
creates the capability for either the parallel or serial use of calculation options. 

The functionality integrated in subblock 1 serves for data flow; this subunit is 
comparable to the ALU of a von Neumann CPU, so the following discussion covers 
the principal differences between a processor and an SLE layer. 

The state control requires a separate logic part, equipped with DNF 2a, 2b, registers 
R2 and multiplexer M2 for destination selection. Various machine types (up to Mealy 
machines) may be integrated in the logic part, even with different clocks as well. 
Generally, the number of states will be small, so there is a sufficient number with (s=) 
5 bit registers (32 states). DNF 2b serves for the decoding of states for control 
purposes. 

Subunit 2 is operatively comparable with the arithmetic logic unit (ALU) of a 
program-controlled unit working according to the Von Neumann Principle, of course 
without the command processing; the states are passed through when triggered by 
external signals. 

The address calculation is optional and is used especially for data transfer in blocks. 
For this purpose, an address increment/decrement and a coupling to the sequence 
control are integrated. The coupling to the microprocessor core and the memory 
should indicate that in this case the source and destination address have to be given. 
Here too the memory coupling in variant 1 is dispensed with (no direct memory 
access). CR3 contains the final address; in AR3 the current address is stored. The 
partition of the logic into DNF3a and DNF3b should indicate that this is a two-stage 
DNF design, since the comparison logic, for example, is very complex for single- 
stage linkage. 

Lastly, the command computation serves for the injection of microprocessor 
commands into the pipeline of the core. In CR4 the corresponding command code is 
stored in order to be able to transmit it along with address and data information. The 
command injection is controlled by means of signals from the state control. The 
connections to the microprocessor core represented on the multiplexers are combined 
into one interface DNF4 for this purpose, which injects a command under the control 
of the state machine. 

The structurable logic can be integrated in any form; NAND arrays, multiplexer based 
variants, and a logic in a disjunctive normal form like the one chosen in this example 
are all possible. Such a DNF based logic arrangement is represented in Fig. 5-6 (see 
also clock subunit, a variation of the diagram below): 
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Abb. 5-6: Altgemeine Struktur der DNF in Abb. 6-6 

The form of DNF represented here makes two-stage logic arrangements possible, for 
instance the combination of DNF2a, R2, and DNF2b with additional output registers; 
at any time this can be reduced to a single-stage logic by leaving out the 2 nd stage and 
integrating the output multiplexer in stage 1 . The scale of the respective logic 
structure must be defined by the system designer; this typifies the flexibility and 
power of the ASSC architecture. 

In closing, it should be noted that, for data group operations, additional storage units 
must be integrated in the SLE. In this case, past data must also be factored into the 
computation, the storage of which should be done not in the memory but in the SLE 
part itself for reasons of performance. 



[translator's note: text continues with paragraph 53] 
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Ein Forschungskonzept zum 
Hardware/Software Co-Design 

Abstract: In diesem Konzeptionspaper wird ein gmndlegendes Modell fiir Hardware/Software 
Co-Design vorgestellt, das auf einer universellen Hardwarearchitektur und einem Ansatz zu einer 
Systembeschreibungssprache basiert. Die Hardwarearchitektur, ats Universal Configurable Block 
(UCB) bezeichnet, kann einerseits direkt struktural programmiert werden; aridererseits wird in 
diesem Paper ein Algorithmus prasentiert, urn prozedurale Programme ebenfalls in einem UCB 
zum Ablauf zu bringen, so daft diese Bl&cke als innerste Bestandteile einer CPU geeignet sind. 
Die Systembeschreibungssprache wird definiert und bietet auf Threadebene eine ideale Plattform 
zur Konfigurierung von UCBs und zur Compilierung in prozeduralen Programme. Die 
endgOltige Architektur, die zur AusfUhrung derartiger Co-Design-Programme geeignet ist, wird 
als Universal Configurable Machine (UCM) bezeichnet und besteht aus einer Anzahl von UCBs 
mit erganzender Hardware. 



1 Einleitung 

Rekonfig^irierbare Hardware, Mufig als Feldprogrammierbare Logikbausteine (FPL) 
bezeichnet, ist in def Bekanntheit deutlich gestiegen: War die strukttirierbare Hardware vor 
einiger Zeit etwas fur Spezialisten, die sich mit dem Ersatz von 'fertigen* Bausteirlen befaBten 
und sogenannte Glue Logic bzw. State Machines einfacher bis mittlerer Komplexitat darin 
implementierten, so hat sich die Gruppe der Forscher und Entwickler in Richtung Informatik 
erweitert. Die Griinde fiir dieseh neuerlichen Attraktivitatsgewinn Uegen in der wachsenden 
GroBe von feldprogrammierbaren Bausteinen, die nunmehr zur Implementierung ganzer 
Systeme bzw. Algorithmen in Hardware geeignet sind, bei glcichzeitig sinkenden Preisen. 

Damit hat sich auch der Charakter von Hardware- Applikationen deutlich gewandelt. 
Rekonfigurierbare Hardware ist sehr schnell, im Vergleich zur Software ahnlich 
piograrnrxiierbar, wenn auch im Detail deutliche Unterschiede bestehen. Es ist jedoch das 
Denken in ganzen Algorithmen bzw. in wesentlichen Kernteilen, das die Einbettung von FPLs 
in ein Rechnersystem nunmehr beeinfluBt. Um hier einige Beispiele zu nennen: DSP- 
Algorithmen, sehr schnelle Steuerungssysteme, Hardware-Beschleuniger. Die Integration von 
Prozessoren und FPL wird im allgemeinen als ein sehr wesentlicher Teil des Hardware/ 
Software Co-Designs [1] angesehen. 

Dieses Gebiet erlebt seit 1991 einen groBen Aufschwung, zunachst in der Forschung. 
Ursprunglich aus dem Ansatz stammend, das Design eines digitalen Systems nicht mehr unter 
dem 'Hardware First' -Ansatz durchzufiihren, spndern Hardware und Software in gegenseitiger 
BeeinfluBung und Abstimmung durchzufiihren, erlebt das Co-Design durch die Verfugbarkeit 
von entsprechend grofien FPL-Bausteinen einen emeuten Schub: Zielsystem ist sehr Mufig ein 
Prozessor/FPL-System oder ein FPL-System selbst. 

Mit diesem Ansatz wird nunmehr der Ablauf von 'Software' im Prozessor und im FPL auf eine 
gemeinsame Basis gestellt Hierzu mufl naturlich der Begriff der Software naher beschrieben 
und eingeschrSnkt werden. Software fiir einen Mikroprozessor/Mikrocontroller besteht auf der 
untersten Ebene aus Instruktionen, die gemaB dem von-Neumann-Modell sequentiell geladen 
und abgearbeitet werden. Dies wird fiir superskalare Prozessoren, die eine nebenlaufige 
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Im folgenden wird eine Alternativarchitektur vorgeschlagen, die viele Aufgaben iml/Q^ereich 
mit keiner oder deutlich verringerter Rechenleistung des Cores durchfuhren kapflfDiese 
Architektur zeichnet sich durch die Einfiihrung strukturierbarer Hardwargrf€mente aus, die 
nach einer Initialisierung sowohl Datentransfers als auch B ercchnungeffdurchfuhren korinea 
Die hier vorgeschlagene Architektur wird als Applikations-sp^zifisch strukturierbare 
Controller- Architektur (ASSC, engl. Application Specipe^tructured Controller) 
bezeichnet 

Zunachst wird eine generelle Struktur auf BlpeKebene entworfen. Der neue Teil innerhalb 
dieses Blockdiagramms wird dann im AbiS^hnitt 5.2 weiter strukturiert und anhand der im 
wesentlichen zu erfullenden AufejfcdS'erlautert. In Abschnitt 5.3 erfolgt danji eine Erlauterung 
des Hardware/Software-Interfiad^s sowie einige Beispiele zu Anwendungeri. 

Der Zusammenhangjprfder >S<puter- Architektur ist zunachst kaum erkennbar. Wahrend der 
>S<puter auf eipsiirhohung der Performance abzielt, bietet die ASSC-Architektur eine 
UnterstttevH^des Echtzeitverhaltens. Am SchluB dieses Kapitels wird daher versucht, den 
Zus^patfflenhang mit Hilfe der UCBs darzustellen. 

5.1 Die ASSC-Architektur auf Blockebene 

Abb. 5.2 zeigt die generelle Struktur der ASSC-Architektur. In dieser Abbildung sind ROM- 
und RAM-Speicherbereich als externe Speichef gezeichnet; dies ist nur exemplarisch zu 
betrachten, da auch speicherintegrierende Architekturen mit einem vergleichbaren, teilweise 
sogar verringerten Aufwand konzipiert werden konnen. 



RAM 



ROM 




Mikrocontroller 



Abb. 5-2: Blockstruktur ASSC-Architektur 

Im Vergjeich zu einer klassischen Mikrocontrollerarchitektur wird in der ASSC-Architektur 
eine Schicht zwischen Peripherie-Elementen und Mikroprozessorkem gelegt, die aus 
strukturierbaren Logikelementen besteht und im folgenden SLE (strukturierbare 
Logikelemente) genannt wird. Innerhalb dieser SLE-Schicht existieren sowohl feste 
Verbindungen des Mikroprozessorkerns auf die Peripherieelemente, urn eine 
Funktionskompatibilitat zu bisherigen Architekturen zu schaffen, als auch konfigurierbare 
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Datenpfade und Datenverkmipfungen, deren detaillierte Struktur im n^chsten Abschnitt und 
deren Kopplung zum Mikroprozessor im ubern£chsten Abschnitt dargestellt wird. 

Die SLE-Schicht kann im Bereich des Datenspeichers in zwei Varianten aufgebaut werden: 

• Variante 1 enthalt keine direkte Schnittstelle zum Datenspeicher. Hierdurch wird ein 
konkurrierepder Zugriff(Core und Peripherie via SLE) zum Datenspeicher grunds&tzlich 
verhindert Die SLE (und daniber die Peripherieelemente),k5nnen den Speicherzugriff 
indirekt durch injezierte Prozessorbefehle durchfuhren. 

• Variante 2 enthalt eine direkte Schnittstelle zum Datenspeicher (in Abb. 5-2 gestrichelt 
angedeutet) und muB daher auch, um konkurrierende Zugriffe ldsen zu konnen, eine 
erweiterte Busschnittstelle anbieten. Der Vorteil dieser Losung liegt in der wesentlich 
schhelleren Bedienung der Speichertransfers bei allerdings erhehtem Aufwand. 

Beiden Varianten gemeinsam sind die ttbrigen Eigenschaften der SLE-Schicht, die ein 
intelligentes, konfigurierbares Interface zwisehen Peripherie und Core sowie den 
Peripherieelementen untereinander bildet. 

5.2 Die Feinstruktur der strukturierbaren Logikelemente 

Prinzipiell ist eine einheitliche Block$truktur in der SLE-Schicht mCglich. Diese besteht dann 
aus ein oder zwei (hintereinander liegenden) Logikblocken fiir disjunktive Normalform (oder 
anderen Basissystemen) v so daB (nahezu) beliebige Kombinationen der Eingangssignale erzeugt 
werden konnen. 

Diese Architektur ist sehr flexibel, erzeugt jedoch eine grofle interne Verschaltungskom- 
plexitat, da jeder Eingang und Ausgang jeweils zweifach an die Logikgatter gefuhrt werden 
muB. Im Rahmen der DNF- Architektur entstehen hierdurch AND-Gatter mit sehr vielen 
Eingangen- Aus diesem Grand wird im Rahmen dieses Papers eine weitere Sub-Blockstruktur 
vorgeschlagen, die die Komplexitat der Gatter mindert; bei entsprechender Wahl der 
Aufteilung sowie Querverbindungen zwishen deh Blocken wird die Flexibilitat der ASSC- 
Architektur hierdurch kaum vemindert. 



Mikroprozessorcore 




I/O-Praipherie 

Abb. 5-3: Interne Struktur der SLE-Schicht 

Die Feinstruktur der SLE-Schicht weist hierzu zunachst zwei interne Blocke aus, die in Abb. 
5-3 dargestellt sind. Der wesentlich kleinere Block dient der Versorgung der strukturierbaren 
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Hardware mit verscfiiedenen Takten, hergeleitet aus einem CPU-Mastertakt. In dieser 
Subeinheit werden beispielsweise Takte mit niedrigerer Frequenz, unterschiedlichem 
TastverhSltnis und ggf. verschobener Phasenlage generiert 

Der wesentlich groBere Teil der SLE-Schicht, die eigentlichen Logikblocke, enthalt mit Hilfe 
von Multiplexern konfigurierbare Datenpfade, Register sowie strukturierbare Logik in Form 
von disjunktiven Normalformen; Multiplexer und strukturierbare Logik kSnnen dabei 
zusammengefaBt werden. Hier werden einzelne Zustandsautomaten mit entsprechenden 
Decodierungen implementiert, die dann die Kopplung zwischen Core und Peripherie sowie 
zwischen Peripherie/Peripherie und Peripherie/Speicher bestimmen. 

5.2.1 Die Teileinheit zur Taktgenerie rung 

t)ie Teileinheit zur Taktgenerierung besteht aus einer schnellen, konfigurierbaren Logik, 
beispielsweise in Form einer disjunktiven Normalform (NICHT-UND-ODER-Logik) mit 
nachgeschalteter, konfigurierbarer Speicherung einschlieBlich Invertierung/PuflFerung und 
Rtickkopplung. Diese Teileinheit besitzt als Takteingang einen, ggf. mehrere CPU-Takte sowie 
eirie Anzahl von k Ausgangen, die alle innerhalb der Logikblockteileinheit als Takt verwendet 
werden konneiu Abbildung 5-4 zeigt den Aufbau auf Gatterebene; diese Darstellung bezieht 
sich auf die bei PALs/GALs ubliche Zeichnungsweise und enthalt die prinzipielle Beschaltung 
von je einem internen Signal und einem generierten Ausgangstakt. 

Die Ausfuhrung als DNF (mit konfigurierbarer Invertierung) gestattet hierbei die Erzeugiing 
einer Vielzahl von Taktvariationen; interne Register/DNFs, die riickgekoppelt sind, sorgen 
auch fur Variationen mit nicht-binaren Tast- und Teilungsverhal^nissen. 




Feedback (j ewe Us normal und invertiert) 



Abb. 5-4: Aufbau Taktgenerierungseinhert auf Gatterebene 
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Die Anzahl der erzeugbaren unterschiedlichen Takte sollte 4 nicht unterschreiten, wahrend 
nach oben eine Grenze durch die Ressourcen gegeben ist. Die untere Grenze fur die Anzahl der 
Terme pro DNF betragt ebenfalls 4. Pro generiertem Takt sollte ein internes Signal zusatzlich 
zur Verfugung stehen. 

5.2.2 Die Teileinheit der Logikblocke 

Wie bereits kurz dargestellt, besteht die Teileinheit der Logikblocke aus verschiedenen 
Komponenten. Hierzu zahlen: 

1 . Konfigurierbare Multiplexer zur Schaltung von Datenpfaden; diese Multiplexer fallen ggf. 
mit der unter 4. genannten strukturierbaren Hardware zusammen 

2. Register in entsprechender Bitbreite zur Zwischenspeicherung von Daten 

3. Bit-Register zur Codierung von Zustanden 

4. Strukturierbare Hardware zur Decodierung von Zustfinden fiir Steuerungssignale 

5. Feste so wie strukturierbare Hardware zur Verkniipfung von Daten miteinahder urid mit 
Konstanten 



Diese Bestandteile werden in folgender, in Abb. 5-5 dargestellten Weise zu einem oder 
mehreren Logikbl^cken gekoppelt. 




Abb. 5-5: Darstellung eines Logikblocks als Teileinheit in der SLE-Schicht 



Im I/O-Teil eines Logikblocks konnen die Daten miteinander verkniipft werden; dies ist in 
konfigurierbarer oder fester Hardware moglich, in Abb. 5-5 werden die Verkniipfungen in den 
DNF la und lb integriert. Die Speicherfunktion in Rl ermoglicht ein Zwischenspeichern, 
wahrend im Konstantenregister CR1 beispiels weise Berechnungskonstanten gespeichert 
werden (z.B. zur Minimiim/Maximum-Begrenzung). 
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Die Multiplexer Mli (Quellenauswahl) und Mlo (Zielauswahl) verbinden den Logikblock rait 
Datenbussen zum Core, Speicher (falls dies zulassig ist, z.B. in Variante 2) und I/O-Elementen. 
Die Konstante k bezieht sich auf die systemimtpanente Datenbusweite, z.B. 16 Bit. Der 
Multiplexer Mli ist dabei entscheidend flir die flexible Kopplung zwischen den Blocken; so ist 
die gemeinsame Berechnung in mehreren Blocken fur eine 1/O-Komponente mSglich, falls die 
Eingangsmultiplexer die entsprechenden Eingangsbusse schalten ktfnnen. Dieses Verfahren 
liefert sowohl Fahigkeiten zur parallelen wie seriellen Nutzung von Berechnungsmoglichkeiten. 

Die in Subblock 1 integrierte Funktionalitat dient dementsprechend dem DatenfluB, diese 
Teileinheitist mit der ALU einer von-Neumann-CPU vergleichbar, wobei auf die prinzipiellen 
Unterschiede zwischen Prozessor und SLE-Schicht an dieser Stelle verwiesen wird. 

Die Zustandssteuerung benotigt einen separaten Logikteil, ausgestattet mit DNF 2a, 2b, 
Registern R2 und dem Multiplexer M2 zur Zielauswahl. In dem Logikteil lassen sich 
verschiedene Automatentypen (bis zu Mealy) integrieren, auch mit verschiedenen Takten. In 
der Regel wird die Zahl der Zustande klein sein, so dafl bei (s =) 5 Bitregistern (32 Zustande) 
eine ausreichende Anzahl vorhanden ist. DNF 2b dient der Zustandsdecodierung flir die 
Steuerung. 

Dx§ Teileinheit 2 ist in ihrer Aufgabe mit dem Steuerwerk einer von-Neumann-CPU 
vergleichbar, wobei die Bearbeitung von BefeMen naturgemali entKllt; die Zustande werden 
durch auBere Signale getriggert durchlaufen. 

Die Adreflberechnung ist optional und findet insbesondere bei blockweisen Datentransfers 
Anwendurig. Hierfur ist ein AdreBinkrement/-dekrement sowie eine Kopplung zur 
Ablaufsteuerurig integriert Die Kopplung zum Mikroprozessorcote und ziim Speicher soil 
dabei andeuten, daB in diesem Fall die Quell- bzw. Zieladresse anzugeben ist. Auch hier entfSllt 
z.B. die Speicherkopplung im Fall der Variante 1 (Entfall des direkten Speicherzugriffs). CR3 
enthalt die Endadresse, in AR3 wird die aktuelle Adresse gespeichert. Die Trennung der Logik 
in DNF 3 a und 3b soil andeuten, daB hier ein zweistufiges DNF-Konzept vorliegen sollte, da 
beispielsweise die Vergleichslogik fiir einstufige Verknupfung sehr komplfex wird. 

Die Befehlsberechnung schlieBlich dient der Injektion von Mikroprozessorbefehlen in die^ 
Pipeline des Cores. In CR4 wird der entsprechende Befehlscode gespeichert, urn diesen 
zusammen mit AdreB- und Dateninformationen ubermitteln zu k6nnen. Die Steuerung der 
, Injektion von Befehlen erfolgt durch Signale aus der Zustandssteuerung. Die an den 
Multiplexern gezeigten Vefbindungen zum Mikroprozessorcore werden zu diesem Zweck in 
einem Interface DNF 4 zusammengefaBt, das bei enteprechender Steuerung durch den 
Zustandsteil einen Befehl injiziert. 

Die strukturierbare Logik kann in einer beliebigen Form integriert werden; denkbar sind hier 
N AND- Arrays, Multiplexer-basierte Varianten und die Logik in Form der disjunktiven 
Normalform, die beispielhaft hier gewShlt wurde. Derartige DNF-basierte Logik ist in Abb. 5-6 
dargestellt (siehe auch Taktteileinheit, eine Variation der unten aufgeflihrten Darstellung): 
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AusgewMhJter Takt 



Ei ngange 
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Abb. 5-6: Allgemeine Struktur der DNF in Abb. 5-5 

Die hier dargestellte Form der DNF ermoglicht zweistufige Logiken, also beispielsweise die 
Zusammenfassung von DNF2a, R2 und DNF2b rait zusatzlichen Ausgangsregistern; dies kann 
jederzeit zu einer einstufigen Logik durch Fortlassen der 2. Stufe und Integration des 
Ausgangsmultiplexers in Stufe 1 verringert werden. Die Ausdehnung der jeweiligen 
Logikstruktur muB durch den Systemdesigner festgelegt werden, sie ist charakteristisch fur die 
Flexibility und Leistungsfahigkeit der ASSC-Architektur. 

Abschlieflend ist zu bemerken, daB bei Datengruppenoperationen zusatzliche Speichereinheiten 
in den SLE zu integrieren sind. In diesem Fall mttssen auch vergangene Daten in die 
Berechnung eingehen, deren Speicherung aus Performancegriinden nicht im Speicher, sondern 
im SLE-Teil selbst vorgenommen werden sollte. 



^fiL^Das Hardware-Software-lnterfaco 

In denkb^gimerbaren Elementen der SLE-Schicht - hierzu zahlen die Multiplexer, die 
VerbindungenlBBethalb der DNF und die Konfiguration der Register - miissen Informationen 
ablegbar sein, die cUisVedjalten der Schaltung reprSsentieren. Die Technologie der 
InfonnationsSpeicherung ist pritsigiell auf drei Wegen vorstellbar: 

• Es werden einmalig herstellbare odeHSsghbare Verbindungen genutzt, die unter den 
Bezeichnungen Fuse bzw. Antifuse bekamn§!»4^piese Verbindungen konnen sowohl 
fabrikatorisch als auch durch geeignete Programmtergorate im Feld gesetzt werden. 

• Zur Informationsspeicherung wird eine EPROM- bzw. EEPKOM^basierte Technologie 
genutzt. Diese Speicherung ist prinzipiell losch- und wiederbeschreiBbas^sie erfolgt durch 



Dipl. -Inf. Sybilie Roth, Prof Dr. Christian Siemens 

EinVorschlag fftr ein Forschungskonzept zum Hardware/Software Co-Design 



Seite 50 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 
✓OIblack borders 

□ image cut off at top, bottom or sides 

□ faded text or drawing 

□ blurred or illegible text or drawing 

□ skewed/slanted images 

□ color or black and white photographs 

□ gray scale documents 
lines or marks on original document 



□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




